This repository has been archived by the owner on Dec 16, 2022. It is now read-only.
Improve logic for determining when to do fallback refresh for post field partials #335
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The changes are part of some experimentation I'm doing (along with JS Widgets) to enable Customize Posts to directly mutate Backbone models created from the WP-API JS client, with the aim of demonstrating patterns for how Customize Posts can be used to manage themes that are rendered purely with JS templates. As part of this I found that we need the partials to be smarter about when they decide that they need to do the fallback behavior of a full refresh. I've introduced the idea of a “fallback dependent selector” which is used to do a test on the document to see whether or not a refresh is warranted. Namely, this selector is intended to normally match the body class or post class that would reference a given post so that if neither the current singular preview or the current archive loop mention a given post, then the fallback refresh behavior should be skipped because the element wouldn't be appearing on the page anyway. As such, this should cut down on some needless full refreshes.